COSGC Robotics Challenge: Toward a Better Beacon

There are many interesting aspects ( hardware and software ) of the Colorado Space Grant Robotics Challenge to be solved including mobility on the sand, obstacle detection and avoidance, general planning, and the use of sensors and actuators in an imperfect world. None of these aspects will lead to a robot that can complete the challenge in the absence of a radio beacon system that allows homing, however. That is the area this project targeted. Specifically, the project consisted of designing an integrated beacon receiver unit that combines the beacon transceiver, a tiltcompensated compass and a processor to make a single module that reduces the work nececessary to include a beacon system on a robot while also increasing the overall performance of the system. A complete hardware and software solution was implemented and preliminary testing done. 1 Rationale Over the past several years of taking part in the COSGC Robotics Challenge, one of the tasks that has taken a disproportionate amount of time at Adams State University has been the preparation of beacon receiver modules for use in the robots. Many solutions to this time sink were considered. Simply building up a cache of hardwired beacon receiver modules that could be used from year to year was considered, as was designing a board to mount the components, and a number of fully custom solutions. The latter seemed to be the most advantageous, all around, for a number of reasons. First, it provided the greatest flexibility as it allowed ( and, indeed, required ) some level of code modification to deal with the new hardware. In the process, it allows smoothing of rough edges in the beacon operation that have become apparent through using them. Beyond the ability to make changes to the function of the receiver as a result of redesigning it, there are added advantages to an integrated system. One major advantage as we push toward more compact challenge entries is reduced dimensions of the electronics which, by extension, allow for reduced robot size. Also, by combining the functionality in a single, dedicated board, using the beacon receiver becomes even easier. As we have tested the current beacon implementation, singularities in the processing have been found which lead to errors under certain circumstances. In sum, the system works; but, it could certainly be improved. There are two preconditions to that improvement however: the beacon receiver needs to have more processing capability, and the method by which the beacon bearing is calculated must be changed. The integrated beacon board allows for the first precondition by upgrading the processor to an LPC1315 from the AtMega328P used in an Arduino. A new software stack provides the change in processing method that will, on average, improve beacon vector calculation. 1 The final advantage to changing the processor and software stack is that the new calculation method provides an estimate of the calculation confidence. This confidence value allows a robot to make decisions about when to follow the beacon vector and when to use other logic for navigation. It extends the current standard beacon receiver’s invalid vector return into a continuous variable that is available along with the vector value. Despite the ability to make even greater strides in performance enhancement and size reduction by redesigning the whole beacon system from the beginning, it seemed, above all, important to keep the new module compatible with the current beacon. This decision ( to retain backwards compatibility ) determined the protocol that the beacon would use in addition to suggesting part selections. In the end, retaining compatibility had the added advantage of reducing the amount of work expended and, similarly, reducing the amount of risk in completing the project. The result of the project is a board ( shown in purple and green, in figure 1 ) that is only slightly larger than the radio receiver board as used in the standard beacon receiver and it includes a radio transceiver, a tilt-compensated compass, a status LED, and a processor. The board connects via an IC bus and provides a number of values: the beacon vector and confidence, the magnetic vector, the accelerometer vector, and the module configuration. 2 Preparation In order to justify the selected approach to estimating the beacon vector, it was necessary to ensure that the the field properties of the rotating beacon transmitter were fairly closely related to the theoretical model of the Yagi antenna’s bimodal distribution. A test receiver was written which parsed the vector packets, associated them with a filtered RSSI ( Received Signal Strength Indicator ) value and dumped the results to a computer. Examples of the collected data sets are shown in figure 2. Although there are noise, missing samples, and a clear bias ( though light ) in some of the recorded examples, the assumed bi-modal distribution remains clearly visible at both the 3m and 6m ranges. Also visible in the recorded signal dumps were higher RSSI values along the primary vector as opposed to in the opposite direction. Not only would it be possible, therefore, to estimate along which line the antenna was pointing, but, indeed, to determine clearly which hemisphere the actual vector lay within. Given that the selected estimation system is implemented as, in essence, a weighted average of angles using the RSSI value as the vector weight, this clearly visible dimorphism in the front and back lobes taken together with the otherwise smooth appearance of the signal was sufficient for the planned estimation approach to work to some degree. Development progressed from there, given that justification. 3 Hardware The hardware of the beacon module is composed of precisely those components that would be expected to have been used historically in configuring a working beacon system. At its core, the integrated beacon consists of three parts: the beacon transceiver module, a compass module, and a processor. The transceiver module has been kept consistent and remains a Linx TRM-433-LT. This ensures optimal compatibility with the existent beacon transmitter systems. To simplify assembly concerns, the compass is a Pololu module which carries an ST LSM303D 3-axis accelerometer / 3-axis magnetometer ( rather than the bare chip, for ease of assembly ). The on-board processor is an LPC1315 manufactured by NXP. This processor is a 32-bit device built around the ARM Cortex-M3 core, can run at up to 72MHz and possesses 12-bit ADC inputs, one of which is used for reading the RSSI of the transceiver. The processor also has 8kB of RAM rather than the 2kB of the AtMega328P. This extra memory allows for largers sets of working data and, thus, more statistically significant calculations. These 2 components are surrounded by power conditioning systems, glue logic, and interface logic. The board also features a tri-color LED for status indication use, and a bank of DIP switches that may, in future, be used to configure the board for different modes of operation without requiring code changes. The board schematic is included in the appendix as figure 3. The board is designed to run from a main power supply in the range of 3.7v up to 12v and has on-board regulation down to a 3.0v rail which is used as the core voltage for all of the major components. This local regulation of the power removes the requirement of providing the integrated module with noise-free, tightly regulated power. In the end, it reduces the noise in onboard sensor readings. Despite running at 3.0v internally, however, the interface to the board has a voltage reference line which is used by translation circuitry. This translation circuitry allows the board to be interfaced to external circuitry that runs with logic levels anywhere between 1.8v and 5.0v, regardless of the main power supply voltage. The hardware design provides, in addition to an IC bus connection, a module reset functionality ( which, due to an error in board layout, is non-functional in the first run of the boards ), and an interrupt line back from the integrated beacon receiver to the control processor. This interrupt line will enable later versions of the software to notify the control processor ( be that Arduino based or other ) of an important state ( for instance, a targeted tracking deviation ). This, in turn, will reduce the necessity of continuous polling by the control processor. While the project as described here was focused on using the board as a receiver system replacement, the board actually supports use as a transmitter as well. The radio transceiver is easily used for bi-directional communication and the antenna is mounted using an RP-SMA connector that would allow, beyond the 1/4 wave whip currently used, any form of antenna, up to and including a Yagi. As such, the board could easily be used to implement the beacon transmitter just as it can be used for the receiver component. Nevertheless, further exploration of that possibility is beyond the scope of this paper. The board was designed in-house using the open-source gEDA tools and the design was sent to OSHPark for manufacture. The board is a simple two-layer, single-side load board which is entirely hand solder-able. Indeed, it was designed to be easily hand assembled. Figure 1 shows the board next to a Parallax transceiver module such as it may be replacing ( together with other circuitry, of course ). By integrating the components on a single board, even in the absence of space saving measures like making the board a double-sided load, it is clear how much space can potentially be saved with the integrated system. Indeed, the entire integrated beacon receiver system is only incrementally larger than just the receiver module in a traditional system. Even with its diminutive size, the integrated beacon receiver board has functionality that is, to this point, yet untapped. One interesting result that came out of the development of these boards was the recognition that the ease with which such boards may be designed and manufactured has improved to such a point that even a small school like Adams State University can profitably consider custom electronics for their projects. This realization has lead to the consideration of a number of other projects ( which remain very much in the thought stages ). Of course, any future projects would most likely proceed along the same lines as the current project and use the same type of standardized interface. 4 Software The code for the integrated beacon is written in modular C++ to make it easily extensible and more easily testable. The basic flow of data is from the radio receiver, through a parser, and into the vector processor. This flow path is supported by a number of other code modules like the magnetic compass, the RSSI reading and beacon rotation detection ( which is used to improve the distribution of accepted vectors ). 3 4.1 Statistics Introduction The processing pipeline uses directional statistics to process a series of beacon vectors into an estimate of the receiver’s bearing from the transmitter. Directional statistics is an extension of traditional statistics to the realm of periodic values – in this case, compass directions. The application of traditional statistics to angles leads to bias in the result because of the effective discontinuity in angular data when treated as linear. This discontinuity in compass data occurs around north. In the absolute worst case ( when averaging values that are at the minimum and maximum angles ), traditional statistics will provide an answer that is half a revolution off from the proper direction. Rather than directly averaging the vector angles, directional statistics converts the angles to unit vectors, adds those vectors, and extracts the angle from the vector components using the inverse-tangent function. A solid introduction to directional statistics may be found in reference [1]. As with traditional statistics, directional statistics allows for weighted averages. This functionality is leveraged to combine the stored vector angle and RSSI values. As a result of using a large collection of data, rather than a few specifically chosen points, noise in the vector angle and RSSI readings can be averaged out. This, in turn, increases the accuracy of the system by lessening the potential for outlier values to drive the estimate away from its true value. An added advantage of using a true statistical method like directional statistics is the ability to extract a justifiable error estimate for the calculated mean. The error estimate used by the current integrated beacon is the circular variance. This statistic is calculated as one minus the ratio of the sum vector magnitude and the sum of weights. It has the nice properties of being range limited within [0, 1], and requiring only minimimal additional calculation beyond the vector estimation. 4.2 Design There are two main paths of data flow in the design: from the beacon transceiver and from the on-board compass. The transceiver path contains a number of sub-blocks. These blocks are deliberately modular so that they might be replaced or modified as needed in the future. The first stop of the beacon data is the transceiver block which is focused directly at interfacing to the board hardware systems. In its current implementation, it configures the TRM433-LT transceiver module as a receiver and initializes the processor’s USART to receive at 9600 baud — as appropriate for the standard beacon protocol. The transceiver block also configures the ADC to sample the RSSI signal value. Although they are not used currently, the transceiver module contains hooks to configure the system as a transmitting device. From the transceiver, the received data bytes are loaded into a circular buffer together with a signal strength value and a byte timestamp in preparation for the parser. The parser module is designed to be easily replaced as future work in developing this project may necessitate a move toward replacing both the physical transceiver module and the current beacon protocol. The simple parser API ( Application Programmer Interface ) will make changes much simpler. All the parser does is to read from the data buffer and write to a similar, circular vector buffer. The parser implementation is not monolithic, however. Some functional units used by the parser are defined as separate classes which can, therefore, be resused with different parser cores for maximum flexibility. These components, such as the rotation timer ( which, logically, estimates how long it takes for the beacon to rotate ) and the vector acceptor ( which selects, based on time and other vector parameters, which beacon vectors should be inserted into the buffer ), are not tied to the beacon protocol and may, therefore, be usable in future systems as well. Also, if the timing algorithm or acceptance conditions were to change in the future, without a change in protocol, it would only require the replacement of 4 a single class rather than the rewriting of more extensive core code. The vector buffer is a circular buffer that ( currently ) stores the last sixty-four vectors accepted. Although all parsed vectors are used in some parts of the code ( for instance, the rotation timer ), vectors are only accepted for inclusion in the buffered set when there is a minimum time between them such that the vector buffer holds, on average, three full beacon rotations worth of evenly spaced data. As the vector buffer is implemented as a circular buffer, it becomes possible for the beacon vector to be estimated in a rolling manner. Rather than requiring a full set of data to be collected for each and every estimate, the estimate is updated for each sample accepted. Thus, beacon vector estimates are updated at a rate of roughly 5Hz ( assuming a typical beacon rotation rate which, for ASU’s transmitter, is between three and four seconds per rotation ). From the vector buffer, data flows into the vector processor which is the component that statistically estimates the beacon bearing. As with the parser module, the vector processor is very carefully designed to be replaceable so that future work can be done to improve the efficacy with which the stored beacon vectors are converted to a beacon bearing. Along a different computation path, the compass module is read, tilt-compensated, and the values ( both raw and calculated ) are stored to be ready for recall. In addition to the calculation, the compass module does all of the hardware configuration and interfacing. It configures the processor’s SPI ( Serial Peripheral Interface ) and configures the LSM303D device. All of the sensed and calculated values are made available in a register-based interface similar to that used in typical external EEPROM and Flash memory devices. The interface is accessed ( via IC ) with a message frame that begins with an 8-bit command and a 16-bit address. Following that, and based upon the command, any number of 8-bit register values may be read from or written to the device. It is expected that a set of low registers ( perhaps the bottom thirtytwo ) will take on defined usages; but, the upper registers are strictly device dependent. The code stack for the integrated beacon has been designed, first and foremost, to be flexible and extensible. At this point, it has reached this goal with the understood proviso that time constraints have impeded the optimal implementation of modular design in some few cases ( which are easily rectified given more time ). Also, the code is based, in part, upon functionality found in the asu-cl ( the Adams State University Control Library ) which is a C++ library compatible with either Arduino or bare metal systems and which provides extended functionality beyond the Arduino libraries. Because of insufficiencies in the asu-cl design with respect to the LPC1300 series processors, the library has not been properly ported and that has led to the asu-cl components being used within the integrated beacon code in an ad-hoc manner. In turn, this led to further fragmentation of the modular design. Still, the code as it stands demonstrates the potential of the system to be developed far beyond the current system and it remains easily configurable ( for instance, for different buffer sizes or protocols ); it is also easy to use. An Arduino library to interface to the integrated beacon has been begun as part of the testing efforts. It provides a reasonably simple method to access the wealth of data provided by the integrated beacon module, however, much work remains to be done to provide a truly stable and easily approachable interface. Moreover, any finished library on the control side must wait until functionality on the beacon has stabilized a bit more. 5 Testing Given a board bring-up period that ended up being only a week ( as a result of the project starting less than a month before the deadline, and the expected delays of manufacture ), there was almost no time to do any testing of the system. Indeed, as it stands there are some very clear bugs in the calculation code that cause incorrect reading of the direction estimate, though the confidence calculation — paradoxically — seems to be cor5 rectly calculated; that is, for vector sets with a strong front to back ratio and minimal noise, the confidence estimate increases just as would be expected over sets wih minimal front to back ratio or high noise. All testing, moreover, has taken place inside a typical school building ( complete with large steel beams and reinforced concrete ) which leads to a number of potential issues as a result of the magnetic field distortion effects of the building’s metallic superstructure. The test system consisted of four major components, as shown in figure 4. A standard Arduino Uno was used as the control processor, an ASU designed power and IC distribution board was used to connect all of the components, the integrated beacon board, of course was used, along with a programmer ( an LPCXpresso board which is a development board with a built-in programmer/debugger ). While this is the form the test system took, it is also representative of what a usable system might look like — subtracting the programmer as it need only be used for development. An even simpler solution, consisting only of the integrated beacon and a control processor, is also possible. Testing proceeded by placing the beacon transmitter in different positions within the room and, therefore, changing the angle with respect to the integrated module. This was done because moving the transmitter was simpler than moving the laptop and test setup with all of their connected wires. The disadvantage to this, however, is that by moving the transmitter, it is placed in magnetically disparate locations. It is known that the room leads to magnetic distortion — sometimes extreme. Still, the entire system — from transmitter, to receiver, through the software stack to vector estimation — was shown to be producing generally believable results. This was checked by streaming the collected and calculated data through the IC connection, to the Arduino, and to the laptop. As mentioned before, a bug in the vector estimation code remains which, sadly, makes the system as a whole unusable in a final robot at present as certain circumstances ( as yet unidentified ) cause wildly inaccurate vector estimates interspersed with the consitent readings. Once this bug is tracked down, the system will be entirely usable. Although usable, however, the system will not be complete. It has much potential to go beyond the functionality that this project has implemented. In the process of integrating the components of the beacon receiver and reformulating the software stack, it became possible to do much deeper analysis of the data. Such possibilities allow for strides in beacon functionality even without changes in the basic hardware used. These are possibilities for a later date. 6 Future Directions The system requires substantially more testing than it has currently received. Given the exceptionally tight time constraints of one month from inception to the current state, the system is necessarily at a very preliminary stage. It serves as a good proof of concept, however. Also, this specific board design and code pipeline are expected to change with further development. First, the interface to the board is a preliminary implementation of what could be used as a standard interface for multiple robot systems well beyond the integrated beacon module as it combines a basic IC bus with reset and interrupt lines. Even the IC protocol used is extensible. It is highly flexible as it presents the system as a set of registers. The basic Arduino library that was written as a test bed for this first design could be extended and refined to act as a base for communication with other devices. This would, in turn, lead to general ease of use improvements for the beacon receiver and, potentially, other sensor or actuator systems as well. A more extensive change to the beacon system would be to transition from the 433MHz transceiver systems that have been traditionally used to a 900MHz system. There are a number of advantages. First, the increased frequency allows for either smaller antennas ( a factor of two length reduction for a 1/4 wave whip ) or use of a more efficient antenna of the same size ( e.g. a 1/4 wave at 433MHz vs. a 1/2 wave at 6 900MHz ). An even larger advantage may be that the move to a 900MHz system will allow for the transition to a more modern transceiver device that provides integrated packet framing, higher data rate capabilities, and built-in RSSI calculation. These features would both provide for both expanded capabilities and simplified implementation of standard capabilities. These benefits would be achieveable while still retaining the nice, long-distance, high-penetration transmission characteristics of a lower transmission frequency. While, at a very basic level, the integrated beacon seems to have come near to meeting its goal of a module that simplifies beacon tracking, there is so very much more that could be done to expand the feature set and optimize the implementation that it seems foolhardy to pronounce the project complete. While it would be just as ill-advised to push to project to the brink of implementing too large a portion of the robot control system, it seems clear that there is yet fertile ground for allowing the beacon receiver to do more from a control standpoint and for exploring other beacon system options even without considering exotic beacon systems. 7 Conclusion To this point, the integrated beacon is demonstrably capable of fulfilling the role of a simple, quickly used component and, thus, the project was able to reach the most basic of its goals. What is just as clear, however, is that the time that was available for the hardware bring-up and initial code testing was wholly insufficient to test and debug the system as might be desired. More work on interpreting the remaining bugs will lead to a more stable and usable system and may also lead to more ideas for future beacon system directions. This project, though just the tip of a very deep iceburg, should make it possible to cease worrying so much about how to complete a beacon system and allow focus to be placed on the, perhaps, more intersting problems of robot mechanics, sensors and sensor fusion, locomotion, mapping, planning, etc. References [1] DIRECTIONAL STATISTICS, By: Gary L. Gaile & James E. Burt